Cut monitor-node CPU: raw health subs, idle-aware task tick - #96

Both sanctioned Python fixes landed, measured on mote-01, and the C++ decision is
taken on evidence — but the evidence is not what the task expected, and the ~5%
target is not reachable in Python. Branch monitor-cpu-tuning, commit d588d08,
unpushed. Write-up: docs/tuning/2026-08-11-monitor-cpu.md with raw sampler
output beside it.

What changed

• health_monitor — the four watched topics are subscribed raw=True. The
  watches only count arrivals and never read a field. /diagnostics stays
  deserialized: it reads status.name/status.level.
• task_server — new idle_tick_period parameter (default 1.0). The tree ticks
  at tick_period only while a task runs. _set_tick_rate resets the timer
  as well as re-periodding it, because setting a period does not move the expiry
  already pending — without the reset the first tick of an accepted tree (the one
  that sends the Nav2 goal) waits out the rest of the idle period, measured at
  2.00 s.
• mote_bringup/tools/node_cpu.py (pixi run node-cpu) — the per-node sampler
  the measurements were taken with, kept so they can be re-derived.
• Tests: test_health_monitor_node.py (new — drives the real node and asserts
  the watched topics are raw, /diagnostics is not, and a raw scan still
  reaches /health and /diagnostics_agg), plus two cases in
  test_goto_tree.py for the tick rates. docs/tuning doc, mkdocs nav entry,
  CLAUDE.md note.

Results (paired, both builds running at the same instant on mote-01)

The acceptance target of ~5% is not met, and cannot be met in Python. The
task's root-cause hypothesis was that these nodes pay to deserialize. Measured:
deserialization is 13% of what a subscription costs; the rclpy wake-up is the
other 87%, at ~0.78 ms of CPU per message delivered to a callback that increments
a counter. Decomposition (four probes, same live graph): bare rclpy node 0.5%;
+7.9 points for 4 subscriptions carrying 101 msg/s; +1.2 for deserializing them;
+4.8 for a single TransformListener on the 51 Hz /tf. health_monitor
consumes ~152 msg/s, so ~12 points are gone before it does anything.

Two corrections to the brief, both load-bearing:

• The TF listener is the biggest single cost, not a footnote. The brief ruled
  it out ("localization is severity: info and low-rate, so it is not the
  cost"); a listener takes the whole /tf stream regardless of which edges you
  ask about. It is also most of what task_server spends while idle, through the
  listener AcquireObject creates in setup() and uses only during a fetch.
• Ticking was never task_server's cost. Dropping 10 Hz → 1 Hz removes 90%
  of the ticks and 12% of the node's CPU. The change is still right (free, and an
  idling tree has nothing to advance) but it is not the lever the figure implied.
• Stage-1 item 3 (swap the odometry TF watch for a topic watch) was measured
  and rejected: both candidate topics are ~50 Hz, so it buys no wake-ups, and
  a fresh topic is not evidence the TF edge Nav2 consumes was broadcast.

Verification

• 418 passed, 2 skipped across mote_bringup/test + mote_tasks/test; the
  five mote_fleet e2e tests that construct TaskServer pass against a real
  mosquitto. pre-commit run --all-files clean.
• The timer-reset test was negative-controlled: with reset() removed it fails
  with "the accepted tree waits 2.00s for its first tick".
• /health and /diagnostics_agg unchanged in content and cadence (1.0 Hz,
  data: OK, mote roll-up first then one status per subsystem); the systemd
  watchdog is still petted on every publish; command acceptance is unaffected
  (it happens in the subscription callback, not on a tick).

Follow-ups filed

• 381 — port health_monitor to C++. Justified by the numbers, and specced
  with the correction above (it must own /tf too).
• 382 — slip_monitor is now the largest consumer at 7.1%. Not portable as
  it stands: its maths is shared with slip_replay.py, which is what calibrated
  slip.yaml, so the shared-maths problem has to be answered first.

Two things to know

• The robot's servo bus is intermittently failing. MoteHardware logs
  Failed to read position from servo 7/9 in bursts; the 50 Hz control loop
  collapses to ~1.6 Hz, /joint_states to 1.6 Hz and /tf to 33 Hz. It
  recovered mid-session (3159 read failures in one run, 564 in the next). Arm
  servos answered throughout, so it looks like the wheel servos specifically —
  worth a look at the wiring. This is also why every result here is paired: a
  sequential before/after over that drift reported the patch making everything
  worse, including slip_monitor, which was not touched.
• The under-mission measurement was not taken. I asked before dispatching a
  goto (it means the robot drives itself) and had no answer, so the figures are
  stack-up-idle with a synthetic 50 Hz /joint_states standing in for a healthy
  control loop. The acceptance criterion is an idle one, and the paired design
  makes the comparison sound regardless — but if you want the loaded numbers, say
  so and it is one more run.

The Pi was left as found: stack down, scratch removed, its checkout untouched and
clean, mote-agent still active. Its code was never modified — the patched
modules reached it through a scratch PYTHONPATH.